Unified Contact Centre Enterprise (UCCE) architecture overview and components

Posted on by Admin

Related Post

Unified Contact Centre Enterprise (UCCE) architecture overview and components

 

I am embarking on a number of posts on Unified Contact Center Enterprise (UCCE) also called IPCC, (same as CUCM is sometimes called Call Manager), I will use UCCE from now on to refer to the suite of functionality that it offers.
 
Why these posts? Well, as always, because I think it is worth sharing and because the topic is something I want to improve on myself as I have not had the exposure to it that I would have liked. For now I have planned a 3 part series, and I want to kick off with explaining the UCCE architecture.
UCCE, same as UCCX right (apart from one letter in the acronym)?  wrong! They are as similar as a Ford Fiesta and a Ford Falcon, yes they both have wheels, they are from the same company and they both drive (well at least most of the time). The same goes for UCCE and UCCX; they are both Cisco products and they both deal with IVRs and Call Centre functionality, but that is pretty much where the similarities end. So, people who put on their resume that they have experience with UCCE simply because the can do UCCX and have put together some aef scripts, have obviously no understanding of UCCE.
 
Back to the UCCE architecture, and lets look the building blocks of UCCE. 
 
First of all, Cisco describes its product as:
 
Cisco Unified Contact Center Enterprise (Unified CCE) is a solution that delivers intelligent call routing, network-to-desktop Computer Telephony Integration (CTI), and multichannel contact management to contact center agents over an IP network. It combines software IP automatic call distribution (ACD) functionality with Cisco Unified Communications in a unified solution that 
enables companies to rapidly deploy an 

 

advanced, distributed contact center infrastructure.

That last part of the last sentence is of course sales crap, and is totally meaningless without a workable context. Anyway, I digress. What this Cisco description does do however, is touch on the different components of the UCCE solution.
 
So as can be seen from the picture below, there are 4 main components to  the UCCE solution:

 

Figure 1 – UCCE Building blocks
  • CUCM
  • Queing and self-service:Cisco IP IVR or Cisco Customer Voice Portal (Unified CVP)
  • Contact Center routing and agent management, which main components are: Call Router/Logger (Rogger), Peripheral Gateway (PG) and the Administration & Data server/Admin Client (AW).
  • Agent desktop Software and integrations with CRM software

1-CUCM

UCCE communicates with Call Manager using JTAPI, as can be seen in the picture below that shows the various software components.

Figure 2 -CTI OS Architecture (source: UCCE SRND)

Interaction using JTAPI, requires the use of an application user on CUCM that has CTI control and Call Monitoring Privileges permissions on the required devices (most notably phones or device profiles, that are used by agents)

2-UCCE components
The UCCE solution consists of the following 3 components.

 Call Router/Logger (aka Rogger)

Makes all routing decisions on how to route a call or customer contact. Often just referred to as the “Router” in the context of Unified CCE components.  The logger resides on the same server and stores contact center configuration data and temporarily stores historical reporting data for distribution to the data servers. Roggers can be set up in redundant fashion, in fact they are redundant instances running on different servers and each on is capable of running the full load. The Roggers run in synchronized execution across the two servers, which mean both sides of the duplex servers process every call. In the event of a failure, the surviving Call Router picks up the call mid-stream and continue processing in real-time and without user intervention.Which is pretty much like statefull firewall redundancy. Furthermore, these roggers require no further, ongoing configuration once deployed. Platform is W2K3.


 Peripheral Gateway (PG)

The PG’s interface to various devices, specifically to CUCM, IP IVR or Multichannel products. This means that if you look at the registered CTI Route Points on CUCM, you will see they are registered under the IP addresses of the PG’s.
They also include one or more Peripheral Interface Managers (PIM’s) for the specific devices. The PG’s run in hot-standby mode, meaning only one PG is active and controlling CUCM and/or IP IVR


 The picture below shows the communication between the PG and the various other components, using PIM’s

Figure 3 – Communications among PG software processes
These “services” can be seen running on the PG, when looking at the task manager (that is right! they do not run as services, they run as Cisco applications).

 

From a call control point of view, the PG’s are it. CUCM communicates to the PG for call set up and tear down, and all the other call control fun stuff. 
Administration and Data Server and Administration Client (AW)

This component forms the administrative portal to the UCCE solution.  It also provides access to real-time and historical data. This is where the UCCE configuration manager Tool lives (more on this later). 


 It is used for instance to configure new teams, agents and supervisors, among other things. 

It also contains the Script Tool, used  to build call routing scripts.
 


The AW component is installed on a separate server (or virtual server). AWs are deployed in pairs for fault tolerance. During normal operation, the primary AW communicates directly with the Central Controller for configuration data (see Figure below) and the secondary AW connects to the primary AW for the data. If the primary AW fails, the secondary AW connects to the Central Controller.

 

Figure 5 – AW communications



3-IP IVR

The Unified IP IVR provides prompting, collecting, and queuing capability for the Unified CCE solution. Unified IP IVR does not provide call control as Unified CVP does, because it is behind Unified CM and under the control of the Unified CCE software by way of the Service Control Interface (SCI) (see Figure 3). When an agent becomes available, the Unified CCE software instructs the Unified IP IVR to transfer the call to the selected agent phone. The Unified IP IVR then requests Unified CM to transfer the call to the selected agent phone. IP IVR communicates with CUCM, using JTAPI, and uses the SCI to communicate with UCCE.
 
The IPIVR server run as a Linux appliance, and is essentially the same as UCCX.


This concludes my first post on UCCE, I hope you now understand why it is so different from UCCX. I am actually hoping I can find some decent diagrams to drill into call control, CTI and JTAPI in my next post. But this is the internets, and anything can happen